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This invention relates to data storage and more particularly to determining end of 



10 incoming data stream in order to create jobs for recording and printing file information on 

1 1 a disc taken from the electronically stored information on the disc. 
12 

13 Description of the Related Art 

14 

15 In the past medical imaging such as x-rays were recorded on film and digital 

16 images were stored on digital film using film laser printers, which is expensive, bulky 

17 and difficult to store. Also, the original digital data might have to be modified so it can be 

18 printed using a laser printer since most printers can not handle high resolution or high 

19 quality digital data. Digital image storage allows storage and retrieval of original digital 

20 data on discs and transmittal of images over communications systems such as the 

21 internet. 

22 There are printers combined with CD recording devices for printing on the disc 

23 that has just been recorded. 

24 Medical imaging data is frequently manually stored on CD's and filed for later 

25 use in doctor's offices, hospitals, clinics and other medical facilities. The medical images 

26 may be generated by x-rays, cat scans, magnetic resonance images, sonograms or other 

27 image generating technologies. 

28 Medical imaging data can be transmitted from one location to another over the 

29 internet or other communication system for recording the data. The filing and record 

30 keeping of the images thus received is a problem. It is a labor-intensive and error-prone 
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1 task to gather information about each disc, write out labels and attach the labels to the 

2 discs, or write directly on the disc for storing and filing. It is very useful to have the 

3 information contained on a disc printed on the disc for reference and filing and for 

4 automatically creating a directory of the information stored on all the discs recorded in an 

5 office. 
6 

7 Summary of the Invention 



10 and prints selected fields of information directly on the discs for ease of file management. 

1 1 The invention also constantly updates a database having a directory of all patient records 

12 and the discs the patient data is stored on. Although the invention is described in terms of 

1 3 storing medical imaging data any data imbedded with information useful for filing and 

14 label printing can be used with the invention. 

1 5 The Medical Data Recording System hardware consists of three main 

16 components: a computer server; a CD autoloader with printer; and a piracy prevention 

17 device. The software components are: DICOM® communication software; FilmX™ 

18 software for storing software for viewing the images on the CDs, software for selecting 

19 image information to be copied to the CD and fields for printing on the discs; software 

20 for creating and updating a database of patient information and autoloader control 

21 software for the CDR and printer; and security device driver software. 

22 The computer server communicates with other medical devices on the network 

23 using the DICOM® protocol. It receives medical images (patient studies) from other 

24 devices, processes the images and burns each patient's images on one or more CDRs 

25 along with medical image viewing software and other files as defined by the DICOM® 

26 protocol as well as files containing printed label definition and graphics files, files 

27 containing patient and study demographics, and necessary system files to make the CD 

28 autorun and autoload. Once a CDR has been burnt, information regarding the contents of 

29 the CDR and other graphics (company logo, legal notices, etc) is then printed directly on 

30 the CDR using the printer attached to the autoloader. Optionally, the system will create 

3 1 back up copies of the medical images it has received by burning them on CDR at 



9 



The present invention automatically scans data received for storage on the disc 
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1 configured days of the week and time. Each back up CDR will contain as many patients' 

2 images as possible to maximize disc space usage. Each backup disc is assigned a serial 

3 number which is printed on it. The patient and study demographics of the backed up data 

4 along with the corresponding backup disc serial number is stored in a database where 

5 they can queried. 
6 

7 Objects of the Invention 

8 

9 It is an object of the invention to print information from selected fields of data 

10 saved on a disc onto the disc for visual recognition such that the discs can be properly 

1 1 stored in files. 

12 It is an object of the invention to reduce clerical time and reduce errors by having 

13 discs printed with information fields from files stored on the discs. 

14 It is an object of the invention to automatically load discs for information storage. 

15 It is an object of the invention to automatically stop recording when the 

16 information stream has stopped and load a new disc for the next patient. 

17 It is an object of the invention to print trademarks, service marks and logos on the 

18 discs. 

19 It is an object of the invention to print selectable fields of information on the 

20 discs. 

21 It is an object of the invention to back up files at specified time intervals. 

22 It is an object of the invention to get as many images as possible onto one CDR. 

23 It is an object of the invention to conveniently store medical image data on 

24 CD's rather than on film. 

25 It is an object of the invention to be able to use a computer display to view 

26 medical images stored on CD's. 

27 It is an object of the invention to preserve medical images for long periods of 

28 time. 

29 It is an object of the invention to create patient files with directories and 

30 subdirectories from image data streams. 

3 1 It is an object of the invention to divide data streams into separate files. 
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1 It is an object of the invention to automatically create and update file databases to 

2 locate patient information on the discs. 

3 Other objects, advantages and novel features of the present invention will become 

4 apparent from the following detailed description of the invention when considered in 

5 conjunction with the accompanying drawing. 
6 

7 Brief Description of the Drawings 

8 

9 Fig. 1 shows a schematic of the system using the data recording system. 

10 Fig. 2 shows a block diagram of the software steps used in the computer for receiving 

1 1 files from the network and storing them on the computer. 

12 Fig. 3 shows the routine for determining the data for jobs from incoming files. 

13 Fig. 4 shows the routine for processing jobs in queue. 

14 Fig. 5 shows the routine for checking for end of jobs. 

15 Fig. 6 shows the routine for the backup process. 
16 

17 Description of the Preferred Embodiments 

18 

19 Figure 1 shows a schematic view of the invention. A medical imaging device 10 

20 such as an x-ray ? cat scan, magnetic resonance imaging, sonogram or other device which 

2 1 generates information for storage on a disc generates images of a patient and either 

22 transmits it or stores it for later transmittal through a communication network 20 such as 

23 the internet to a computer 30. The computer 30 can be used to select information to be 

24 stored by the compact disc writer 40 on compact discs, CDs, 42 and can select what 

25 information is to be printed by printer 44 on discs 42. Although CDs 42 are shown, any 

26 recording medium may be used for storage of information. The blank compact discs 42 

27 are stacked in an input CD stack 43 waiting to be recorded. The CD autoloader 46 selects 

28 CDs 42 from the top of the input CD stack 43 to be recorded on and places the CDs 42 

29 into the recorder 40. When the CD 42 has information stored on it, it is moved by the CD 

30 autoloader 46 to the printer 44 where selected information and logos or other graphics are 

3 1 printed on the CD 42 so that the users have a written record on the disc of the information 
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1 stored thereon and logos identifying the producer of the disc or other information. The 

2 CDs 42 are then removed from the printer 44 by CD autoloader 46 and placed in the CD 

3 output tray 45. The CDs 42 can then be placed in patient files. 



5 software communicating to an attached piracy prevention security device that keeps track 

6 of how many CDs are being recorded and what product option are active. There is 

7 software to run the autoloading functions of the CD autoloader 46 for recording and 

8 moving discs 42. The software also can be programmed to select the fields of information 

9 to be printed on the discs and for printing logos or other graphics or information on the 

10 discs. The software also copies instructions for operating the imaging onto the disc so 

1 1 that a computer without imaging software loaded in it can view the images on the discs. 

12 Although many different software programs can be used to accomplish the goals 

13 set out above the following shows one method of securing image information for later 

14 viewing and recording it on discs with labels printed thereon. The software described 

15 herein is called FilmX™ software by the applicant. 

16 FilmX™ software is used to receive data in the computer 30 from the 

17 communication network 20. The software incorporates DICOM® network connectivity 

18 software 51 such as WinSCP32.exe which is currently a standard digital imaging protocol 

19 used in the industry to receive the digital imaging data from the imaging device 10. The 

20 imaging data is received in the computer 30 by use of network connectivity software 51 

2 1 using "winSCP32.exe" software available from ETIAM Corporation; Rennes, France. 

22 This program is a Storage Service Class Provider using the DICOM® protocol The 

23 computer 30 receives DICOM images that are sent to it and places them in the Incoming 

24 ("D:\Incoming") directory 52, The files are named :<S to rage SOP Class>.<SOP Instance 

25 UID>.dcm where <Storage SOP Class> is the SOP class of the image and <SOP Instance 

26 UID> is the image UID (Unique Identifier). 

27 There are multiple timers defined with in FilmX.exe. Timer_l 60 is responsible 

28 for checking for incoming new files 61 in Incoming Directory 52. If new files are 

29 received they are stored as a separate file in a temporary directory Temp Directory 63. 

30 Timer_l 60 is programmed to check if an end-of-patient-data timeout (MaxTime) 65 has 

31 occurred. The value for Timer 1 60 is defined in the FilmX.ini file and is hence user 
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The software for running the invention performs several tasks. There is security 
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1 configurable. Default time for Timer_l 60 is 1 (one) second. Max Time 65 is also user 

2 configurable via FilmX.ini and is set to 30 seconds for default. The system will not allow 

3 that time to be set less than 10 seconds. Once the Timer_l 60 goes off, two routines are 

4 called: 
5 

6 DcmBTreeParselnputDirectory 

7 dcmBTreeMakePatientDataAvailable 
8 

9 The first routine parses any DICOM Part 10 file found in Incoming Directory 52. 

10 If any new files 61 are available, they are transferred to the Temp Directory (d:\Temp) 

11 63. For each different patient, a subdirectory is created under the Temp Directory 63, and 

12 for each study of this patient, a subdirectory is created under the patient directory. 
13 

14 Patient differentiation is based on Patient Identification which consists of the 

15 concatenation of information found in DICOM datasets: PatientsID '_' PatientsName, 

1 6 without any ' A ', any white character or any character that may lead to an invalid Windows 

17 directory name, all characters are uppercase and enclosing blanks are removed. 

1 8 Patient Directory name underneath Temp Directory 63 is the Patient Identification 

19 described above. 

20 Study identification is based on the StudylnstanceUID. Study Directory name 

21 beneath the Patient Directory is the study identification referenced above. 

22 Filenames are the original filenames found in Incoming Directory 52. This allows 

23 the system to override an image if it is sent twice. 

24 An additional text file is created in each Patient Directory. This file has a fixed 

25 name (timestamp.bsy) and contains the date and time of the last image insertion in the 

26 Patient hierarchy. The following information is also written in this file: 

27 • PatientsName 

28 • PatientsSex 

29 • PatientsBirthDate 
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An additional text file is created in each Study Directory. This file has a fixed 



2 name (study. dsc) and contains the information extracted from the last image of the study 

3 inserted in the Study Directory. This information is as follows: 

4 • StudyDate 

5 • StudyTime 

6 • StudylD 

7 • StudyDescription 

8 • RefferringPhysiciansName 

9 • AccessionNumber. 
10 

1 1 Once DcmBTreeParselnputDirectory has returned, any new patients are added to 

12 the Incoming Patient Queue and displayed on the screen as such. The combination of 

13 patient "[id]_[name]" is now the internal job name used for tracking the job. 

14 Then dcmBTreeMakePatientDataAvailable is called to check in Temp Directory 

15 63 if any patient subdirectories have not been modified (some images added) since 

16 MaxTime 65 seconds ago. The number of unmodified directories since MaxTime 65 

17 seconds is returned. If no new files 61 have arrived for a patient, the timestamp file 

18 (timestamp.bsy) for the patient will be renamed to a fixed filename (timestamp.rdy). 

19 Once the function returns a positive number, we browse for Patient Directories in 

20 the Temp Directory 63 containing "timestamp.rdy" file. The entire patient hierarchy is 

21 then moved to the Backup Directory 71 (D:\Backup). The Job is then removed from the 

22 Incoming Patient Queue and added to the Pending Patient Queue and displayed as such. 

23 If inactive, Timer_2 70 is activated to start processing the pending job(s). 

24 Timer 2 70 is responsible for moving jobs pending in Queue to be processed. 

25 Once it goes off, the system is checked for any patient in queue 72, if none are present, 

26 TimerJZ 70 is disabled in step 74. If there are pending jobs in Pending Patient Queue, 

27 the system is checked for patient in process 73 (being recorded or printed). If there is 

28 one, Timer_2 70 is disabled and it returns. If there are no patients in process 73, the next 

29 job in Pending Patient Queue, is processed. The patient directory hierarchy in Backup 

30 Directory 71 is moved to the Build Image Directory 75 (D:\Build Image) to get ready to 

3 1 burn on CDR(s). The Build Image Directory 75 also contains a Viewer Directory 
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1 ("Wiewer) where the viewing software resides. There is also a FilmX Directory 

2 ("FilmX") in the Build Image Directory 75 which contains the Patient information file 

3 ("Patient.txt") and the Xlabel Directory ("\Xlabel") where the CD printing label 

4 definitions and graphics files reside. Since DICOM Exchange standards only allow for 

5 eight character file names, the Patient, and Study directories as well as image file names 

6 are converted to eight character format in processing step 76. The Patient Directory 

7 name is changed to "PT000000" for the first patient. In case of back up CD, Patient 

8 Directories are then sequentially named "PT000001" and so on. The Study 

9 Directory(ies) are named starting with "ST000000" and increase sequentially if there is 

10 more then one study for the patient. The image files are then named starting with 

1 1 'TM000000" and so on. On the Build Image Directory 75 there is also an "autorun" file 

12 which is recognized by the Windows operating system and executed when a disc is 

13 inserted in a computer. The "autorun" file contains instructions to start the viewer in an 

14 "autoload" fashion causing it to immediately load and display the first Patient's first 

15 Study. Finally, according to DICOM Exchange standard, a "DICOMDIR" file in 

16 generated in step 76 in the Build Image Directory 75. 

17 Once the Build Image Directory 75 is complete, it represents what should be put 

18 on the final CDR with Build Image Directory 75 as the root of the CD. The computer 

19 program "Premaster.exe" is then called to create a CD image of the contents of the Build 

20 Image Directory 75. This program is part of the BuzzSaw® software package produced 

21 by ISO Media of Seattle, Washington. The result is a "[job].CDR" file which is the 

22 image of the final CDR. It is located in the Spool Directory 77 (E:\Spool). A "[job].job" 

23 file containing the job control information for the autoloader control software 

24 (Buzzsaw®) is created in the Spool Directory 77. The Job file specifies the name of the 

25 CDR file, the input file for the print label fields, the number of CDRs to be made, the test 

26 flag, and other fields as required by the Buzzsaw® software. Once the CD image files is 

27 generated in the Spool Directory 77, the Build Image Directory 75 is then cleared of the 

28 patient directory and other created files. Once created, the job file is recognized by the 

29 Buzzsaw software and processed. 

30 Buzzsaw® instructs the autoloader 46 to pick up a new CDR 42, put it in the 

3 1 CDR drive 40. Once there, Buzzsaw® will proceed to record the contents of 
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1 "[jobj.CDR" file on the CDR 42 in the drive 40. In rnulti-copy, multi-drive situations, 

2 Buzzsaw® will place new CDRs 42 in other drives 40 as well and record them 

3 simultaneously. Once the recording is finished, Buzzsaw instructs the autoloader 46 to 

4 place the recorded CDR 42 in the Disc Printer 44. It will then execute the printing 

5 software to print the label containing the input fields on the CDR. 

6 The label printing software and printer driver are supplied by Primera 

7 Technologies; Plymouth, Minnesota, a disc printer manufacturer. The label definitions 

8 allow for input fields to be merged into the label via a merge file in Build Image 

9 Directory 75. The patient.txt file in the Build Image directory 75 is that merge file. 

10 Once printed, the CDR 42 is then placed in the output bin 45 by the autoloader 46. 

1 1 If there are multiple copies, the other CDRs 42 are then printed by the Disc Printer 44 and 

12 put on the output bin 45 as well by the autoloader 46. Buzzsaw then updates the status 

13 line at the bottom of the "[job], JOB" file contained in the Spool Directory 77 to indicate 

14 the j ob is completed. 

15 Timer_3 80 is responsible for checking the end of the job. Once Timer 3 80 goes 

16 off, the system checks for job done 81. If so, the job is moved from the Patients in 

17 Process to Patients completed and display is updated in step 82 where Timer S 80 is 

18 cleared, and Timer_2 70 is enabled. If Backup Enabled 83 is false, the patient directory 

19 is deleted from Backup Directory 71 . Otherwise, it will be kept there to be used during 

20 the backup. 

21 Timer_4 90 starts the backup process. It is programmed to go off at the 

22 configured time on the configured day(s) of the week. The program then checks if there 

23 are any files to backup 91. This is also a check for the end of back up process. If 

24 finished (or nothing left to back up), a CDR 42 containing only the latest database files is 

25 generated 99. This is the backup disc for the database files. If there are files to backup 

26 91, in Select Patients step 92 enough patients are selected to fill a 650 MB CD (if there 

27 are enough) minus approximately 10 MB which is used for storing system, label, and 

28 viewer files. A Backup CD unique serial number is also generated in Select Patients step 

29 92. The patient directories are then moved from Backup Directory 71 to Build Image 

30 Directory 75. The same processing as for a patient CD, as described in steps 75 - 77 

31 above then occur steps 93-95. Once a backup job is created, the software then goes 



